TLS 1.3 Is Moving Forward: What You Need to Know Today to Get Ready

Updated September 25, 2021.

Last month the Internet Engineering Task Force (IETF) approved version 1.3 of the TLS (Transport Layer Security) specification to move to the standards track.¹

What is TLS 1.3? TLS is the newest version of the TLS stack, which is itself the newer version of SSL (Secure Sockets Layer), although we still hear both terms being used interchangeably. Prior to this approval, TLS 1.2 was the most recent version of the protocol. TLS is a standard to secure communications between web applications and web browsers, but more generally between clients and applications that typically sit over a reliable transport layer such as TCP, although there have been adaptations to UDP as well.

TLS provides three key services:

• Confidentiality: Ensuring that anyone snooping the communications between the client and server cannot decipher the content.
• Authentication: Ensuring that a client is in fact talking to the server that the client thinks it is talking to.
• Integrity: Ensuring the messages and communication have not been tampered with.

The confidentiality is ensured by leveraging encryption algorithms and symmetric cryptography, the keys of which are negotiated during an initial TLS handshake. The authenticity is established by using certificates, once again exchanged during the initial handshake. The integrity is ensured by using a Message Authentication Code (MAC).

TLS 1.3 has several changes that improve performance and security, while also eliminating several complexities and simplifying the protocol stack. Along with that, there are implications for enterprises that use network security-based solutions for compliance, risk management as well as threat hunting.

While there are many changes in TLS 1.3, two of the salient updates are described below along with their implications.

• One of the key performance improvements in TLS 1.3 is speeding up the time it takes to negotiate protocol versions, cipher suites and authenticate the server. This is typically done during the initial handshake between the client and server. In TLS 1.2 this would typically take two round-trip times (2-RTT). Simply put, a round trip time (RTT) is the time it takes for a client to send a message to the server and for the server to respond back to the client. The TLS 1.2 handshake would take 2-RTT due to multiple messages being exchanged between the client and server during the handshake. In TLS 1.3 this initial handshake has been cut down to 1-RTT. Furthermore, there is the ability for clients to “remember” previous sessions and essentially resume the session without wasting even 1-RTT. This would allow session resumption with a 0-RTT making for far lower overhead.
• Another major difference in TLS 1.3 is that the use of static RSA and Diffie-Hellman key exchange has been removed, being replaced with ephemeral mode Diffie-Hellman, thereby providing forward secrecy. Forward secrecy means that if someone at some point in the future got access to a server’s private key, they should not be able to crack all the past conversations if they also get access to a conversation log. Essentially, this ensures that compromise of a private or long-term key in the future should not compromise the confidentiality of all past sessions. Ephemeral mode Diffie-Hellman accomplishes this by coming up with a unique one-time key for each separate conversation between a client and server. Even if attackers recorded and stored previous encrypted conversations, they would need the keys to each individual conversation to decode them. A single session key won’t decode all the other conversations, or subsequent conversations. In addition to the use of ephemeral mode Diffie-Hellman, all handshake exchanges between the client and server after the initial client hello are encrypted. This includes all the certificate data used in the handshake.

The implications of these changes are significant:

• The 0-RTT changes will lead to faster time to connect to and load web pages, do transactions on the internet and in general bring a more responsive browsing and internet experience. There are some security implications associated with “resuming” a session with 0-RTT – potentially creating a vulnerable window of opportunity for replay attacks. Suggestions to mitigate this are described in the latest TLS 1.3 internet draft, and servers moving to TLS 1.3 implementations should implement these as appropriate.
• Many organizations today leverage network security appliances that need to inspect the data that is traversing their network. This is needed to identify malware, attempts to exfiltrate data, potential beaconing and C2 (Command and Control) communications, and other malicious communications. In some instances, content inspection is also used for troubleshooting, as well as for monitoring application performance. Devices that do this type of decryption may sit in a passive or out-of-band mode, or may be in-line to the network traffic either as a bump-in-the-wire device or as an active network element such as a firewall or Intrusion Prevention System (IPS). Inline devices typically function as a man-in-the-middle,  intercept a client’s connection to an application server and set up a separate connection to the client and to the server, each of which terminate on the man-in-the-middle device. Passive mode deployments are common in many large enterprises, particularly those that have strong regulatory and compliance requirements. When deployed in a passive mode, decryption of traffic is possible when:
  1. Using the RSA key exchange.
  2. The server or application’s private keys are shared with the decryption device.
  3. Traffic is typically in-bound to the application server.
• With TLS 1.3, this passive mode decryption will no longer be possible since the RSA key exchange has been removed. This means that organizations that were leveraging passive mode devices that decrypted content, based on policies, will no longer be able to do this for the purposes of threat hunting or regulatory compliance. This is a large change and one that will force many industries to re-architect how they do security, compliance or monitoring. It could also slow down the adoption of TLS 1.3. Note that inline man-in-the-middle device solutions for decryption are still possible – for now – and organizations may be able to take advantage of these types of solutions to enhance their compliance and security posture. There is a practical limitation that you can only deploy man-in-the-middle devices in so many places, since almost all such solutions do introduce some latency. Hence equivalent coverage, for example for east-west traffic, would be difficult to achieve.
• Another area of potential impact with TLS 1.3 is all packets in the handshake after the initial encryption of the client hello. This includes the server certificates. Network security solutions that relied on understanding the information in the TLS handshake – for example examining the server certificate to help identify self-signed certificates or other anomalous situations – will no longer be able to do so. Once again, this impacts passive-mode network security solutions. Inline solutions may still be able to decrypt the traffic and examine certificate data or other data in the TLS handshake, for anomalies or threat hunting. Again, the limitations outlined above, i.e., the number of places where this can be done, will be limited due to practical considerations. But at least for internet traffic, this may be a possibility.

From an adoption and timing perspective, while some browsers today are already shipping with TLS 1.3 capability, the internet-wide and industry-wide rollout of TLS 1.3 will take time. There are still implementations of TLS 1.0 and 1.1 out there today. While some browsers may support TLS 1.3 quickly, and indeed some already support it today, organizations that are impacted by the above changes may be slower to migrate their application servers to TLS 1.3. They first need to understand how to re-adjust their compliance and security stack.

The shift to TLS 1.3 may also be hampered by the presence of man-in-the-middle network devices that do TLS decryption. Since these devices implement the TLS stack themselves and serve as a TLS proxy, intercepting a client’s TLS connection to the server, until these devices also migrate, the adoption of 1.3 may be limited.

TLS 1.3 will allow a connection to down-negotiate to TLS 1.2 where either side does not support TLS 1.3 and this applies to man-in-the-middle devices as well. However, certain previous implementations of TLS were challenged with the ability to down-negotiate correctly as described in this blog.² And while TLS 1.3 has attempted to address some of these challenges, expect there to be some hiccups between the client browser, the man-in-the-middle solution and the application server, as each of them upgrade independently – or not – to TLS 1.3.

In summary, TLS 1.3 has significant changes, improvements and some simplifications over previous TLS versions, and can improve the security and performance of internet communications and transactions. However, the rollout of TLS 1.3 may take some time and organizations should carefully understand their compliance and regulatory requirements, and the role of their network security solutions while taking a phased migration approach.

Citations

1. https://www.ietf.org/id/draft-ietf-tls-tls13-28.txt

2. https://blog.cloudflare.com/why-tls-1-3-isnt-in-browsers-yet/